The present invention provides a robust, consistent and safe hardware implementation of the SONET pointer interpretation function. This pointer interpretation function is specified to some extent in Bellcore Document TR-TSY-000253 and in CCITT recommendation G.783.
However, the standard suggested by the CCITT/ETSI AU-4 pointer is slightly different than that specified by ANSI/Bellcore STS-3C pointer. The STS-3C pointer comprises three concatenated STS-1 pointers, #1, #2 and #3 as shown and described below.
The AU-4 pointer also comprises three pointers of which one pointer (#1) carries the pointer value and #2 and #3 are not used and carry fixed values as also shown below.
______________________________________ CCITT/ETSI AU-4 H1 and H2 #1 H1 and H2 #2 H1 and H2 #3 Normal NDF+ss+ NDF Enabled+ NDF Enabled+ Offset rr+All 1's rr+All 1's BELLCORE STS-3C H1 and H2 #1 Normal NDF+rr+ NDF Enabled+ NDF Enabled+ Offset rr+All 1's rr+All 1's ______________________________________
Although the range of offset values for AU-4 and STS-3C are the same; namely, from zero to 782, there is a difference of the ss versus rr bits since CCITT/ETSI has defined the ss bits to represent the transported synchronous payload envelope (AU-x, TU-x). Bellcore and ANSI have yet to define the rr bits and currently they are considered "reserved". This lack of definition requires the rr bits to be set to 0's by transmitters and ignored by receivers to meet the North American Standard. Such a definition incompatibility of bits 5 and 6 can cause problems because CCITT/ETSI uses these bits to determine the pointer state when implementing the pointer interpretation algorithm. If a CCITT/ETSI pointer interpretation circuit is to receive 0's in the ss bit when expecting something else, it should declare the pointer word invalid and initiate the loss of pointer status.
There are also differences in the definition of the pointer states between CCITT/ETSI and Bellcore. CCITT/ETSI documentation includes state diagrams for pointer interpretation. Bellcore documents do not include state diagrams, but only word descriptions. FIG. 1 is an illustration of the CCITT/ETSI state diagram while FIG. 2 is a state diagram interpretation of the Bellcore requirements. The state diagram used in association with the present invention is presented in FIGS. 3A and 3E. In particular, the present invention uses an algorithm implemented in hardware so as to create an Alarm Indication Signal (AIS) and NO AIS state machine and a loss of pointer (LOP) and NO LOP state machine. These hardware implemented state machines are then mapped through an algorithm to produce a single equivalent state diagram as shown in FIGS. 3A and 3E.
CCITT has attempted an interpretation of the CCITT pointer interpretation requirements in their document identified as G.783.
The Bellcore TR-TSY-000253 document states that the removal of AIS is to be detected as one of the following conditions: A valid pointer observed for three consecutive frames with NDF=0110 or a valid pointer value with NDF=1001. A transition from AIS to LOP is not defined. It is believed that such a requirement is necessary and likely to be added in the future. Based on the Bellcore document, if a non AIS condition (not all ones), but also non-valid pointer condition persists after an AIS has been declared, the AIS alarm is not removed, thereby providing inaccurate information about the status of the pointer. It is believed however, that LOP is a more appropriate status in such a situation.
CCITT recognizes this condition and has added a path from AIS to LOP, however it does not have full coverage of the case described above.
Another shortcoming with the prior art relates to random pointers which can result in unreliable LOP detection (latched LOP). The Bellcore TR-TSY-000253 document definition of a valid pointer is not complete. The Bellcore requirement to enter LOP is no valid pointer in eight consecutive frames. If incoming pointers are random with at least one in eight meeting the valid pointer definition, then an LOP alarm is never declared. Clearly this should be an LOP condition since a valid pointer value cannot be established.
Although CCITT has a more implicit definition of valid pointer, LOP detection of random pointers has the same deficiencies.
It is not possible to derive a hardware implementation to meet all the current requirements and not be subject to hardware change if future requirements change. In addition, each pointer processor design could possess different characteristics due to the wide range of interpretation possible from the requirement documents.
The present invention provides a system which overcomes the aforementioned difficulties. In particular, the present invention overcomes the above mentioned difficulties by treating an AIS condition as a subset of the LOP condition, exiting the AIS state when all ones does not exist for three frames, and defining an LOP as any sequence of pointers that do not meet the requirement to establish a valid pointer value within eight frames.
By making AIS a subset of LOP, LOP is active when AIS (all ones) is persistent. The present invention removes the AIS when all ones is not present for three consecutive frames. If during these three frames the criteria for establishing a valid pointer value does not exist (three consecutive matching in-range pointers with NDF=0110 or one in-range pointer with NDF=1001), then the LOP condition persists. With this information provided to associated software, the associated software can easily be modified to latch or not latch the AIS alarm from the system perspective. If the requirements change with respect to latching AIS, extensive hardware changes can be avoided.
The published requirements for exiting LOP are clear (three consecutive matching in-range pointers with NDF=0110) while the requirements for entering an LOP state are incomplete and inconsistent as explained above. The present invention operates on the criteria that if the requirement to exit LOP does not exist, then the system should be in an LOP state. Thus the present invention has defined a valid pointer as three matching in-range pointers with NDF=0110. If a valid pointer is not seen for eight consecutive frames, an LOP is declared. Such a declaration prevents random pointers with repeating values from not causing entry of the LOP state.
Normally, three consecutive matching pointers are guaranteed at least once every four frames even in the presence of pointer adjustments. This result guarantees at least two matching pointer opportunities in every eight frames under the maximum rate of pointer movement. Therefore the present invention is error tolerant to one in eight errorred pointers due to bit errors.